IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalized, rich multimedia communication services, including so-called “combinational IP Multimedia” services which are considered in more detail below.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7. IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardized IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically the IMS architecture according to 3GPP Release 5 (R5) and IMS Release 6 (R6). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. The user receives a unique URI from the S-CSCF that it shall use when it initiates a dialog. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if one is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. [It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.] When a registered user subsequently sends a session request (e.g. SIP INVITE) to the IMS, the request will include the P-CSCF and S-CSCF URIs so that the P-CSCF is able to forward the request to the selected S-CSCF. This applies both on the originating and terminating sides (of the IMS). [For the terminating call the request will include the P-CSCF address and the UE address.]
Within the IMS service network, application servers (ASs) are provided for implementing IMS service functionality. Whilst it was originally envisaged that ASs would operate as “slaves” to the IMS CSCFs, responding to requests delegated by the S-CSCFs, this need not be the case and indeed it is now expected that ASs may have interfaces to external (i.e. non-3GPP) networks, and may receive an internal stimulus to perform an action (e.g. a timer expiry). FIG. 2 illustrates the IMS Service Control (ISC) interface between an AS and an S-CSCF, as well as other interfaces within the IMS. Although the AS in FIG. 2 is shown as having only a single interface to an S-CSCF it will be appreciated that in practice the ISC interface will extend across a communication network to which many (or all) of the CSCF servers of a given operator's network are connected, allowing an AS to communicate with all of these CSCFs. [Other entities illustrated in FIG. 1 will be well known to those of skill in the art.]
User services in this architecture are invoked by linking in Application Servers on the ISC interface for originating and terminating requests based on filter criteria that are provisioned for the user in the HSS and executed in the S-CSCF upon request. In 3GPP IMS an Application Server can assume different roles with respect to service delivery and interaction with the S-CSCF. Example roles are shown in FIGS. 4 to 7, which show respectively: Application Server acting as terminating UA, or redirect server; Application Server acting as originating UA; Application Server acting as a SIP proxy; and Application Server performing third party call control.
A further interface (Ut) exists between the AS and the user terminal (TS23.002) although this is not shown in the Figure. The Ut interface enables the user to manage information related to his or her services, e.g. creation and assignment of Public Service Identities, management of authorization policies that are used for example by “presence” services, conference policy management, etc.
The current IMS architecture allows for an AS to initiate an IMS session in response to the receipt by the AS of an appropriate request over an external interface. One might for example envisage that an IMS session request is sent to the AS over an HTTP interface, where a user initiates the sending of a request by accessing a web page on the Internet. In this case, upon receipt of the session request, the AS will first contact a Home Subscriber Server (HSS) of the initiating user to determine whether or not the user is already registered with the IMS. The AS sends to the HSS a SIP identity generated for the user and which the HSS can use to determine whether or not the user is registered. If so, the HSS will send to the AS the identity of the S-CSCF already allocated to the user. The AS will then forward a SIP INVITE to the identified S-CSCF, and the session set-up procedure will continue as illustrated in FIG. 3. An example scenario where this situation might arise is where a 3GPP mobile subscriber is registered with the IMS, and the subscriber then logs on, via a home PC, to a web page and requests an IMS session via that channel.
If it is the case that the user is not registered already with the IMS, and this is reported to the AS by the HSS, the request cannot be processed. TS.228 specifically states that “If the AS could not acquire a S-CSCF address for the Public User Identity, the AS shall not initiate a session on behalf of the user”. It will be appreciated that a similar problem arises where the stimulus for establishing an IMS session is generated internally, within the AS. For example, one can envisage a scenario where the AS has been requested to perform an update of a user's status on a presence server at a requested time. As in the case of an externally originating service, the current standards will allow the AS to initiate the require IMS session only if the user in question is registered with the IMS.
Whilst the discussion above relates to a user that is assumed to be a user possessing a public user identity, the user may be an application, i.e. possessing a public service identity.